Isn't ocp-safe-sfr-map linked to a specific comid component? I'm not understanding what purpose fw-identifiers serves in the ocp-safe-sfr-map, as this information should be available (or inferable) from the component the ocp-safe-sfr-map is attached to.

I think when this came up in the meeting it was agreed to keep these as optional attributes that can be filled out by the SRP to help with standalone use-cases beyond attestation. These are some of the ones mentioned in the meeting:

• Being able to know the on-disk hash of the FW binary file an SFR endorses during platform provisioning
• In the case of the SRC only audits the src-manifest provides the ability to describe all source files audited
• Repo tag helps with logistics of future/delta audits by providing a starting point for changes

I'm asking a slightly different question here:

• Won't this endorsement already be associated with an exact hash of a specific FW component?
• If so, what information does the fw-identifier provide that cannot be inferred from that hash? (which will necessarily correspond to a specific commit in a specific repo)

I think the intent is to make it easier for a human to understand what specific Firmware is being endorsed by looking at the fw-identifier if it is present. The 'exact hash' you mention is the runtime hash of the FW which is probably only in one other location, the Vendor CoRIM for that Firmware release.

Further for source only audits there is no 'runtime hash' that an SRP can endorse. Hence a repo tag is probably the best way to identify the source for the audit, and can be verified using the manifest hash.

Similarly, if there is no runtime measurement being used for Firmware that doesn't get measured for attestation, an On-disk hash gives the recipient of such FW the ability to verify that the binary file they received indeed corresponds to what the SRP audited.

the CVSS-related entries should be generic to allow for other vuln rating systems

I thought we talked about making the assessment-schema a required field that can be an cvss-schema or jil-schema, etc. Something along the lines of:

issue-entry = {
  &(title: 0) => tstr
  &(description: 1) => tstr
  &(assessment-scheme: 2) => $assessment-scheme
  ?&(cwe: 3) => tstr
  ?&(cve: 4) => tstr
  * $$ocp-safe-issue-entry-ext
}

$assessment-scheme /= cvss-scheme

cvss-scheme = {
  &(cvss-score: 0) => tstr
  &(cvss-vector: 1) => tstr
  &(cvss-version: 2) => tstr
}

I don't like the naming for assessment-scheme given that block is capturing the issue scoring as well. Maybe "issue-assessment" instead? Otherwise, I like the arrangement.

How about something like:

issue-entry = {
  &(title: 0) => tstr
  &(description: 1) => tstr
  &(assessment: 2) => $assessment
  ?&(cwe: 3) => tstr
  ?&(cve: 4) => tstr
  * $$ocp-safe-issue-entry-ext
}

$assessment /= cvss

cvss = {
  &(score: 0) => tstr
  &(vector: 1) => tstr
  &(version: 2) => tstr
}

looks good to me. I'm not familiar enough with JIL to comment on the proposed scheme below but I'll prod some folks who are for feedback.

needs a category for security chips (eROT/PaROT/dTPM/etc). Maybe also a category for FPGA/CPLD.

historically this field has been treated as a free-form text description. Does limiting to a numerical enumeration provide the granularity needed? who actually consumes this value?

From CBOR perspective "free form text" is discouraged. We did discuss this in one of the prior meetings and agreed to enumerate them. We can extend the categories as needed.

Here is my proposal:

Does address your concern @syncsrc-nv ?

Yeah, this is good. A couple comments on the proposed change:

• Should "iROT" be an example for the root-of-trust option? It's not a stand-alone device, I would expect the category for an iROT to be that of device the iROT is embedded in.
• May also want to expand the ROT option to include other stand-alone secure-element and TPM type devices that might not normally be classified as a ROT due to their limited functionality. Or provide another category for them.

another possible category suggested to me: power-delivery (for UPS/PSU/PDU/etc.)

I'd like to better understand the use case for the device category field. From my perspective, each SAFE entry is already uniquely identified by the tuple (Vendor, Model, ClassId), and it's the device vendor's responsibility to document what each tuple represents in their reference values.

My concern with adding an enumerated category field is that it may blur the line between the endorser's role (augmenting device evidence) and the vendor's role (documenting their products). Additionally, any fixed enumeration risks becoming outdated as new device types emerge that don't fit existing categories. @ericeilertson

My interpretation was that this field was describing the evaluation rubric that was applied, which would not come from the device vendor.

As mentioned above, this was historically descriptive free-form text provided by the vendor. I think Fabrizio is hinting that maybe this field can be removed entirely. It is definitely of unclear value in its current form, and has noted issues in the proposed form.

@ericeilertson I tend to agree that the value of the 'category' field is not clear. I would be in favor of simplifying the schema and removing it all together. Can we bring this as an open in the meeting, or even an email discussion to try and expedite the discussion/decision?